…ally

GetCustomersByUsageAttribution returned an unordered []Customer, so
callers (governance + a private-repo consumer) each built their own
map[key]Customer with first-match-wins semantics that depended on DB row
order — unfixable by reordering when two customers collide on the same
key from opposite sides (one's own key vs. the other's subject key).

Service now returns map[string]Customer with key-over-subject precedence
resolved once, centrally, mirroring the single-key lookup's UNION ALL
priority. Each ambiguous collision is logged with the key and both
customer IDs for operator follow-up, replacing the duplicated (and now
provably buggy) mapping loops in every consumer.

Isolates namespace size from the customers/features axes
BenchmarkGovernanceQuery already covers: fixes query load at 100
customers x 1 feature, varies decoy customers/subjects seeded directly
via SQL (HTTP creation would dominate setup time at 100k+). Confirmed
against the pre-fix bulk lookup: latency scales with namespace size
(38ms -> 160ms at 0 -> 100k decoys); post-fix it stays flat (48ms ->
54ms), matching the adapter-level benchmark's win.

Moves initE2EPostgresPool into helpers.go so both this and the
existing ledger e2e check can share it.

… size

decoyCounts hardcoded 10_000 as the middle tier; GOV_BENCH_NAMESPACE_DECOYS
below that seeded up to 10_000 first, then skipped seeding for the smaller
tier (seeded > target) while still reporting the smaller, now-incorrect
count as the benchmark label. Sort + dedup keeps the sequence monotonic
regardless of the env override.

…ibution lookup

Bulk subject-key matching added a CreatedAtLTE guard the single-key path
never had, diverging from its own eager-loaded subject list and forcing a
second query to reconcile them. created_at is server-assigned and immutable,
so a future-created subject can't occur in production. Remove the guard to
restore parity with the single-key predicate.

Trim redundant clauses in two comments (governance namespace-scale
benchmark doc, bulk usage-attribution created_at-guard note) that
restated the same point twice or over-qualified it. No behavior change.

…bution lookups

Give the subject-branch owning-customer check the same Or(IsNull, GT(at))
grace window as the key branch in both GetCustomerByUsageAttribution and
GetCustomersByUsageAttribution, so a customer resolves identically via its
own key or a subject key. Behavior-equivalent in production (deletion always
stamps clock.Now().UTC()); adds CustomerDeletedInFutureIncluded tests.

…resolve precedence in service

Delete the single-key adapter GetCustomerByUsageAttribution and its SQL-precedence
helper (lookup_priority / ORDER BY / LIMIT). Both single-key and bulk lookups now use
the one customersMatchUsageAttributionKeys predicate; the single-key service method
calls the bulk adapter with a one-element key set and applies key-over-subject
precedence in Go via resolveCustomersByKey. The service signature and error contract
are unchanged (validation / not-found-same-message / never-conflict), so no OSS or
downstream consumer changes.

Drop the ambiguous-match logging from both single and bulk paths: key-over-subject
collisions are structurally rare and resolved deterministically, so resolveCustomersByKey
now returns only the resolved map. A benchmark of the single-key path (SQL-side vs
Go-side precedence) confirms it is perf-neutral, with slightly fewer allocations.

…ution core

Route the single-key and bulk GetCustomer(s)ByUsageAttribution service methods
through one resolveCustomersByUsageAttribution helper (adapter fetch + precedence)
so their core resolution can't drift. Rename resolveCustomersByKey to
resolveCustomersByKeyWithPrecedence to name its key-over-subject behavior.

Add Test_GetCustomersByUsageAttribution covering key/subject resolution,
key-over-subject precedence, unmatched-key-absent (no error), and empty-key
validation, mirroring Test_GetCustomerByUsageAttribution. The fully symmetric
{K1,K2} cross-collision is left to the unit and adapter tests: CreateCustomer's
overlap guard rejects a customer key that overlaps another customer's subject,
so that state can't be constructed through the service.

The adapter benchmark inlined a copy of the service's key-over-subject
precedence, mixing layers and risking drift from resolveCustomersByKeyWithPrecedence.
Split into layer-honest benchmarks:

- adapter package: BenchmarkCustomer(s)UsageAttribution*Query measure only the
  candidate query (cross_table_or vs union_all), no precedence.
- service package: BenchmarkCustomer(s)UsageAttribution*Lookup drive the real
  service.Get(s)ByUsageAttribution end-to-end, exercising the real precedence.

Shared seed/count/bulk-key fixtures move to a new leaf package
customer/testutils/uabench (imports only the ent client, so both benchmark
packages use it without an import cycle). The inline precedence copy is deleted;
the seed SQL is unchanged.

Run the timed loop of the bulk service benchmark inside b.Run so it gets a
fresh, running timer: the previous flat form called b.StopTimer() during setup
and b.ResetTimer() (which does not restart a stopped timer), so the loop was
measured with the timer off and reported no ns/op.

Test-only, no production change.

Rebase onto main changed the harness: NewTestEnv migrates internally and
InitPostgresDB takes PostgresDBStateEntMigrated. Drop the leftover
DBSchemaMigrate call and stale comment, and the now-redundant Schema.Create
in the adapter and service benchmarks.